Open topic with navigation

Program Flow

The script engine executes based on the structure of the destination data definition. This is termed the program flow and is the order in which the See "Events" are executed by the script engine.

The script engine executes based on this destination data definition, running through its datasets and fields executing the events. This happens in a predetermined order however it is possible for the user to control this order of execution with special functions in the script.

To describe the program flow it is best to illustrate it with an example. Mapping is about converting a source data definition into a destination data definition. For the purpose of the example we have the following data definitions. The source data definition is reading from a Informix database, and the destination is connected to a MSSQL database. The effect therefore

Source Data Definition

This data definition represents a list of orders and contains three datasets ORD_HEAD, ORD _LINE, and LINE_MESG. By the symbols next to the linking line you can determine the hierarchy and therefore which is the child dataset (the infinity sign is the child). In this case LINE_MESG is the child of ORD_LINE which is again the child of ORD_HEAD.

This data definition therefore contains a list of orders, each order having one or more lines, and each line having one or more messages. Lets pretend that there are 10 orders in total within the data definition - 10 ORD_HEAD records each with 5 ORD_LINE records, each with 2 LINE_MESG records.

Destination Data Set

This data definition again represents a list of orders and contains three datasets ORDER_HEADER, ORDER _LINE, and LINE_MESSAGES. For simplicity the datasets are very similar to those in the source except they have different names.

This data definition therefore will contain a list of orders, each order having one or more lines, and each line having one or more messages. Until the mapping has occurred this data set is empty. The purpose of the map is to fill the data set and save it to somewhere.

Within the map editor these data definitions are shown in a tree format representative of their hierarchy. The source data definition is on the left and the destination data definition is on the right

The script engine is based off the destination data definition and therefore when the map executes the following program flow occurs.

1. The ORDER_HEADER dataset is processed - the events against the dataset fire and then the events against each of its fields are fired. This results in one record being created in the ORDER_HEADER dataset.
2. The ORDER_LINE dataset is processed - the events against the dataset fire and then the events against each of its fields are fired. This results in one record being created in the ORDER_LINE dataset. This record is linked to the ORDER_HEADER record.
3. The LINE_MESSAGES dataset is processed - the events against the dataset fire and then the events against each of its fields are fired. This results in one record being created in the LINE_MESSAGES dataset, and this record is linked to the ORDER_LINE record.
4. At this point the processing finishes

However the processing doesn't necessary have to finish there (and most likely it won't). What happens next depends on whether the LinkedData event is set for any of the datasets (Refer See "Events"). The LinkedData event is a special event that indicates whether a source dataset is linked to this dataset.

When there is no LinkedData the destination dataset is processed once and therefore one record is created.

Let's now assume for this example that the equivalent source dataset is linked to the destination dataset (ie ORD_HEAD linked to ORDER_HEADER). The script engine will now scroll through the records of the linked source dataset until it comes to the end. If there is a child dataset however it processes that first before scrolling to the next record in the source.

A dataset has only one active record at a time. The script engine determines the end of the dataset when it sees no more records, however the script engine only sees the records in the child dataset that match to the parent dataset. When the mapping first starts, record 1 of the ORD_HEAD is active - the script engine only sees its 5 ORD_LINE records, of which the first one of these is active meaning the engine only sees the 2 LINE_MESG records for that active ORD_LINE record.

Remember that in this example the source dataset has 10 orders within it, each with 5 lines, and each of those with 2 messages. The following program flow will therefore occur:

1. The ORDER_HEADER dataset is processed and record 1 from ORD_HEAD is translated to ORDER_HEADER
2. The ORDER_LINE dataset is processed and record 1 from ORD_LINE is translated to ORDER_LINE
3. The LINE_MESSAGES dataset is processed and record 1 from LINE_MESG is translated to LINE_MESSAGES
4. The LINE_MESSAGES dataset is again processed and record 2 from LINE_MESG is translated to LINE_MESSAGES. This is because LINE_MESSAGES has no child datasets and is linked to the LINE_MESG dataset. It therefore keeps processing until all the LINE_MESG are processed, and there are 2 messages for the currently processed order line.
5. The ORDER_LINE dataset is again processed and record 2 from ORD_LINE is translated to ORDER_LINE.
6. The LINE_MESSAGES dataset is processed and record 1 from LINE_MESG is translated to LINE_MESSAGES (this is message record 1 of the second order line)
7. The LINE_MESSAGES dataset is again processed and record 2 from LINE_MESG is translated to LINE_MESSAGES (this is message record 2 of the second order line)
8. The ORDER_LINE dataset is again processed and record 3 from ORD_LINE is translated to ORDER_LINE
9. ...
10. Eventually after 5 ORDER_LINE records are processed, the ORDER_HEADER record is again processed and record 2 from ORD_HEAD is translated to ORDER_HEADER.
11. The whole process occurs again until all records have been processed from the linked source datasets.

In essence the first ORD_HEAD record is processed, then each of its ORD_LINE records, and each of the LINE_MESG records in between each line. Eventually the next ORD_HEAD is processed and the loop continues until no data is left in the source data definition.

The user can modify this program flow through special See "Program Control" functions in the script.